interesting linux tricks part 2: building on memory mappings to hijack running processes

From: flushy@flushy.net
------------------------------------------------------


In my previous post I showed you how to use memory mappings exposed by 
the /proc file system to view the memory of a running process you 
already can access.

# Injection using memory maps

In this post, I build on that concept to show you a project and my 
example project that uses it, to run an arbitrary payload in an 
environment where you shouldn't

# DDexec

A security researcher, Yugo, developed this POC, written in shell 
script, to show how to read in an arbitrary file, decode the execution 
metadata, inject it into the current process (the shell), and run it.

https://github.com/arget13/DDexec

I wrote an example exploration of this project, using read-only 
containers.

https://github.com/gonoph/ddexec_example

# What's it do?

  I've explained a lot in the project, but in a nutshell:

If you have podman or docker installed, run the script.

It will create a read-only container that has anything writable (like 
/tmp) mounted as "noexec" which means you are unable to run binaries 
directly.

It will download the ddexec script from Yago.

Then it will feed a sample "rogue" application from the internet to 
ddexec.

The rogue application will display tux the penguin saying you're hacked. 
(It's just text.)

Oh, and it will do all of this without actually downloading anything to 
the file system.

# Why you should care: The Impact

None of this is surprising or novel by itself. A non-root user can 
execute programs. They can manipulate processes they started and own. A 
root user can do the same, except to any process on the system.

This is normal.

What is not normal is having the ability to execute a program on a 
system where you shouldn't: read only and no execute.

Combined with other weaknesses, this type of attack could be used to 
commandeer workloads, to launch other reconnaissance against your 
network from a trusted application, or to poison data, record your 
customer activity or more.

It's flawed to think a single technology can protect our networks.

Read only, no execute environments should be immune to this attack, but 
they are not.

That's a big impact.

It's also a cautionary tale, that we should be utilizing a layered 
approach to security, and treat things that interact with the public as 
"untrusted."

Let me know if you find this interesting!

I have more (hopefully interesting) projects coming soon!

--b